I have been working on integrating our custom DXL code into the DOORS 9.2 client. I noticed LS_ , NLS_ , and NLSTEMP_ functions seem to be new and are use throughout the client DXL code. Does anyone have any information about these functions?
Thanks,
Lee
Lee_Bost - Mon Sep 28 11:23:07 EDT 2009 |
|
Re: New DOORS 9.2 Undocumented DXL Functions llandale - Fri Nov 13 09:48:07 EST 2009
I see these in the v9.2 doors.exe, meaning they are basic 'perms':
string getLocalizedString(string, string)
string NLSTEMP_(string)
string NLS_(string)
string LS_(string, string, string) // lsResource
string LS_(string, string)
The one parameter calls return the input string. (NLSTEMP_ and NLS_)
The two/three parameter callsm return the 2nd parameter.
Looking through the deployed code, I see that an NLS_ call is usually the 2nd parameter of an LS_ call.
I speculate, and hope others can chime in:
'LS' is apparently 'LocalizedString'.
'Temp' is I presume like tempStringOf(Buffer), string conversion that doesn't eat up string table space.
'N' is perhaps 'Non'.
I guess: this is all an attempt to reduce wasted string table space, where these strings exist only once and the doors string table does NOT grow slowly and steadily over time, the more you use DOORS.
|
|
Re: New DOORS 9.2 Undocumented DXL Functions Mathias Mamsch - Sat Nov 14 16:02:05 EST 2009 llandale - Fri Nov 13 09:48:07 EST 2009
I see these in the v9.2 doors.exe, meaning they are basic 'perms':
string getLocalizedString(string, string)
string NLSTEMP_(string)
string NLS_(string)
string LS_(string, string, string) // lsResource
string LS_(string, string)
The one parameter calls return the input string. (NLSTEMP_ and NLS_)
The two/three parameter callsm return the 2nd parameter.
Looking through the deployed code, I see that an NLS_ call is usually the 2nd parameter of an LS_ call.
I speculate, and hope others can chime in:
'LS' is apparently 'LocalizedString'.
'Temp' is I presume like tempStringOf(Buffer), string conversion that doesn't eat up string table space.
'N' is perhaps 'Non'.
I guess: this is all an attempt to reduce wasted string table space, where these strings exist only once and the doors string table does NOT grow slowly and steadily over time, the more you use DOORS.
lol, if this is an attempt to not waste string space, why are the functions returning "strings".
Localized Strings are normally used to have different languages in your code, the content is assigned at runtime regarding on your site parameters (e.g. system language).
If IBM would start trying to fix all the crap in the DXL language it would be very costly. Example: Can you tell me another language that uses an arbitrary constant for uninitialized variable values?
int v // uninitialized ...
int *rv = &v
print "Uninitialized Value: " (*rv) "\n"
int x = -2023406816 // uninitialized value - 1
print "X = " x "\n"
x++
print "X = " x "\n" // this fails with "x is not initialized"
And for everyone who is wondering why this arbitrary constant: -2023406815 = 0x87654321
Regards, Mathias
|
|
Re: New DOORS 9.2 Undocumented DXL Functions Tony_Goodman - Thu Dec 30 16:09:08 EST 2010 Mathias Mamsch - Sat Nov 14 16:02:05 EST 2009
lol, if this is an attempt to not waste string space, why are the functions returning "strings".
Localized Strings are normally used to have different languages in your code, the content is assigned at runtime regarding on your site parameters (e.g. system language).
If IBM would start trying to fix all the crap in the DXL language it would be very costly. Example: Can you tell me another language that uses an arbitrary constant for uninitialized variable values?
int v // uninitialized ...
int *rv = &v
print "Uninitialized Value: " (*rv) "\n"
int x = -2023406816 // uninitialized value - 1
print "X = " x "\n"
x++
print "X = " x "\n" // this fails with "x is not initialized"
And for everyone who is wondering why this arbitrary constant: -2023406815 = 0x87654321
Regards, Mathias
Did anyone find out any more about these intriguing perms?
Tony
|
|
Re: New DOORS 9.2 Undocumented DXL Functions Mathias Mamsch - Thu Jan 06 16:57:58 EST 2011 Tony_Goodman - Thu Dec 30 16:09:08 EST 2010
Did anyone find out any more about these intriguing perms?
Tony
Hey Tony,
as Louie already said, the perms
string NLSTEMP_(string s)
string NLS_(string s)
do nothing, but returning the parameter you pass to them. Maybe they have been used to give them a function later, but at the moment they are pretty useless.
The perms
string LS_ (string key, string fallback, string repository)
string LS_ (string key, string fallback) // repository defaults to 'core' repository
string getLocalizedString (string key, string fallback) // exactly the same as LS_ (in DOORS 9.2) !!
will search the language repository 'repository' for a string with the key 'key'. If the key is found, then the value from the repository is used, otherwise the 'fallback' string is returned. The repositories can be found in the DOORS language directory. With my DOORS 9.2 I see two repositories (each one a directory) shipped 'core' and 'DXL'. Each one contains a binary resource file containing the strings. The repositories are taken from the open source project ICU (International Components for Unicode) , a project IBM is actively supporting, I think. A good choice regarding DOORS 10, since ICU exists in a C and a Java version. So on the web site you can probably find the description of the resource file format.
Example:
string x
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "DXL")
print "Confirm DXL: " x "\n" // prints 'confirm' on my english installation
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "core")
print "Confirm core: " x "\n" // the string 'confirm' is also in the core repository
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "no such rep")
print "Confirm 'no such rep': " x "\n" // fallback since repository does not exist
x = LS_("no_such_key",NLSTEMP_("fallback :-("), "DXL")
print "No such key: " x "\n" // fallback since repository does not exist
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: New DOORS 9.2 Undocumented DXL Functions Stefanhunsicker - Thu Feb 03 06:48:47 EST 2011 Mathias Mamsch - Thu Jan 06 16:57:58 EST 2011
Hey Tony,
as Louie already said, the perms
string NLSTEMP_(string s)
string NLS_(string s)
do nothing, but returning the parameter you pass to them. Maybe they have been used to give them a function later, but at the moment they are pretty useless.
The perms
string LS_ (string key, string fallback, string repository)
string LS_ (string key, string fallback) // repository defaults to 'core' repository
string getLocalizedString (string key, string fallback) // exactly the same as LS_ (in DOORS 9.2) !!
will search the language repository 'repository' for a string with the key 'key'. If the key is found, then the value from the repository is used, otherwise the 'fallback' string is returned. The repositories can be found in the DOORS language directory. With my DOORS 9.2 I see two repositories (each one a directory) shipped 'core' and 'DXL'. Each one contains a binary resource file containing the strings. The repositories are taken from the open source project ICU (International Components for Unicode) , a project IBM is actively supporting, I think. A good choice regarding DOORS 10, since ICU exists in a C and a Java version. So on the web site you can probably find the description of the resource file format.
Example:
string x
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "DXL")
print "Confirm DXL: " x "\n" // prints 'confirm' on my english installation
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "core")
print "Confirm core: " x "\n" // the string 'confirm' is also in the core repository
x = LS_("String_Confirm",NLSTEMP_("fallback :-("), "no such rep")
print "Confirm 'no such rep': " x "\n" // fallback since repository does not exist
x = LS_("no_such_key",NLSTEMP_("fallback :-("), "DXL")
print "No such key: " x "\n" // fallback since repository does not exist
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Hi all,
has anybody found a way to use this feature in own DXL scripts?
Every .res file put in a new subfolder of the "language" directory seems to be ignored ...
Thanks and best regards,
Stefan
|
|
Re: New DOORS 9.2 Undocumented DXL Functions Mathias Mamsch - Thu Feb 03 18:56:09 EST 2011 Stefanhunsicker - Thu Feb 03 06:48:47 EST 2011
Hi all,
has anybody found a way to use this feature in own DXL scripts?
Every .res file put in a new subfolder of the "language" directory seems to be ignored ...
Thanks and best regards,
Stefan
Hmm ... Trying with the ICU tools, it seems to work very nicely. Here is a little walkthrough:
1. Download the ICU 4.0 binary release from the ICU website:
http://download.icu-project.org/files/icu4c/4.0.1/icu4c-4_0_1-Win32-msvc8.zip
2. Create a two language for the languages you want to use, e.g.:
Create a file en.txt:
en {
key1 { "german language, hard language" }
}
Create another file de.txt
de {
key1 { "Deutsche Sprache, schwere Sprache" }
}
Extract the ICU binaries, go to the 'bin' directory, copy both text files there and execute:
genrb -d . de.txt en.txt
This should have create two files 'de.res' and 'en.res' in the 'bin' directory.
3. Create a new Directory "MyRepo" in the languages directory. Put the de.res and en.res inside there.
4. Execute the following DXL program:
string x = LS_("key1","fallback", "MyRepo")
print "The string is: " x "\n"
This should print out the string depending on your language (german or english). I appended the res files in a zip file, so if you want you can try with them.
Hope this helps, regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Attachments
attachment_14578658_res.zip
|
|